Subject: DLSw version 0.12 (8 of 8)

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Mon, 15 Aug 94 13:49:25 PDT

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 10
X-Sun-Content-Length: 214

Here is the eigth and last part.

Combine parts 1 through 8 to get a full ASCII spec.

Postscript and full ASCII version are on the FTP server (see
previous anouncement for details.

Happy reading,

Alan

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: dlsw8.txt
X-Sun-Content-Lines: 584
X-Sun-Content-Length: 16703

RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

   NOTE: From a flow control perspective, the two frame headers are handled
   identically.

   The following diagram describes the format of the Flow Control Byte

   (EDITOR's QUESTION:  THE ORIGINAL PROPOSAL SHOWED BITS NUMBERED 0 TO 7 (LEFT TO
   RIGHT).  I AM CHANGING THIS TO MATCH PAUL BRITTAIN'S SUBMISSION WHICH USES 7 TO
   0 INDICATING THE BITS AS A POWER OF 2.  DID YOU WANT THE FCI BIT TO BE MOST OR
   LEAST SIGNIFICANT??)

   bit   7   6   5   4   3   2   1   0
       +---+---+---+---+---+---+---+---+
       |FCI FCA|  FCO  |    reserved   |
       +---+---+---+---+---+---+---+---+

   FCI : Flow Control Indicator
   FCA : Flow Control Ack
   FCO : Flow Control Operator Bits

         00 - Repeat Window Operator
         01 - Increment Window Operator
         10 - Decrement Window Operator
         11 - Reset Window Operator

   A frame with the FCI bit set shall be referred to as a Flow Control Indication
   (FCIND).  An FCIND is used to manage the flow in the opposite direction of the
   frame which bears it.

   A frame with the FCA bit set shall be referred to as a Flow Control
   Acknowledgment (FCACK).  An FCACK is used to manage the flow in the same
   direction of the frame which bears it.

   NOTE:  A frame may be both a FCIND and an FCACK.

   A frame bearing an FCIND or FCACK may also contain data for the flow in the
   direction it is traveling.  In such a frame, the FCIND or FCACK are said to be
   piggy-backed.  A non-piggy-backed FCIND is called an Independent Flow Control
   Indication (IFCIND) and a non-piggybacked FCACK is called an Independent Flow
   Control Acknowledgment (IFCACK).

   NOTE:  A frame may be both an IFCIND and an IFCACK.

5.3. Granting Permission to Send Data

   A receiver shall grant a sender permission to send units of data by sending
   FCIND.  Each FCIND is further qualified by a flow control operator, which is
   encoded in the FCO bits of the FCIND header. With one exception (the Reset
   Window operator) all operators may be either piggy-backed carried in a IFCIND.

A.K. Bartky                                                  [Page 66]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

   The four flow control operators are outlined below:

5.3.1. Repeat Window Operator

   This operator shall be processed as follows:

   (CurrentWindow unchanged)
   GrantedUnits += CurrentWindow

5.3.2. Increment Window Operator

   This operator shall be processed as follows:

             CurrentWindow++
             GrantedUnits += CurrentWindow

5.3.3. Decrement Window Operator

   This operator shall be processed as follows:

             CurrentWindow--
             GrantedUnits += CurrentWindow

   NOTE:  This operator may only be sent if CurrentWindow is greater than one.

5.3.4. Reset Window Operator

   This operator shall be processed as follows:

             CurrentWindow = 0;
             GrantedUnits  = 0;

   NOTE:  This operator may only flow on an independent pacing indication ( may
   NOT be piggy-backed).

   NOTE:  After sending this operator, the only legal subsequent operator shall be
   Increment Window.

5.4. Acknowledging a Flow Control Operator

   Each sender must acknowledge each FCIND with an FCACK which is piggy-backed on
   the next frame in the opposite direction in all cases except the Reset Window
   Operator.

   The receiver may have no more than one unacknowledged FCIND outstanding at any
   time with one exception:  A Reset Window Operator may be sent while another
   FCIND is pending acknowledgment.

A.K. Bartky                                                  [Page 67]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

   NOTE: The FCI and FCO bits of the FCACK are used independently by the flow in
   the opposite direction

5.4.1. Acknowledging a Reset Window Operator

   Since this operator revokes all previously granted units, the sender must
   acknowledge this FCIND using an IFCACK (Independent Flow Control
   Acknowledgment).  This is the only case where IFCACK is used.

   Should a sender receive a non-reset FCIND followed by a Reset Window FCIND
   before acknowledging the first, he shall only acknowledge the Reset Window.

   NOTE: The FCI and FCO bits on these frames are used independently by the flow
   in the opposite direction.

5.5. Capabilities Exchange

   When two standards-level nodes establish a transport connection, they shall
   engage in a capabilities exchange.  This protocol of this exchange is beyond
   the scope of this document.

   It should be noted, however, that the two nodes shall be required to exchange
   the following parameter:

   InitialWindowSize -  This shall indicate to the partner what the sending
                        flow entity shall initialize its CurrentWindow
                        value two for each multiplexed session subsequently
                        established on that transport connection.  This
                        value must be non-zero.

5.6. Session Startup

   Process as follows:

          CurrentWindow = InitialWindowSize
          GrantedUnits  = 0

5.7. Example Receiving Implementations

   The following two examples illustrate receiving implementations of varying
   degrees of complexity.  These are not meant to be complete implementation but
   rather serve to illustrate the protocol.

   NOTE: The examples are independent of the buffering model ( buffers may be
   deterministicly or statistically committed)

   NOTE: The examples assume a process model where each event processes to
   completion without being preempted by another event.

A.K. Bartky                                                  [Page 68]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

5.7.1. Fixed Pacing Example

   Consider the following variables, in addition to InitialWindowSize and
   CurrentWindow and FCACKOwed:

      GrantDelayed     - Boolean
      GrantedUnits     - Outstanding Units

   The following section describes how various events are processed in this
   example implementation:

5.7.1.1. Circuit Startup

          CurrentWindow    = InitialWindowSize
          FCACKOwed        = FALSE
          GrantDelayed     = FALSE
          GrantedUnits     = 0
          Repeat Window Operator

5.7.1.2. Check Buffers Available

          Can my implementation afford to grant CurrentWindow just now?

5.7.1.3. Buffers Become Available

          IF Check Buffers Available THEN
             Send FCIND( Repeat Window)
             GrantDelayed = FALSE
          ELSE
             Wait on buffers to become available (LIFO)
          ENDIF

5.7.1.4. Repeat Window Operator

          IF Check Buffers Available THEN
              Send FCIND( Repeat Window)
          ELSE
             GrantDelayed = TRUE
             Wait on buffers to become available (FIFO)
          ENDIF

5.7.1.5. Send FCIND( operator)

          GrantedUnits += CurrentWindow
          FCACKOwed     = TRUE
          Encode and Transmit FCIND piggybacked or as IFCIND

5.7.1.6. A Frame Arrives from Sender

A.K. Bartky                                                  [Page 69]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

          GrantedUnits--;
          IF frame is FCACK THEN
             IF FCACKOwed THEN
                FCACKOwed = FALSE
             ELSE
                Protocol Violation
             ENDIF
          ENDIF
          IF NOT GrantDelayed THEN
             IF GrantedUnits <= CurrentWindow THEN
                 IF FCACKOwed THEN
                   Protocol Violation
                 ELSE
                   Repeat Window Operator
                 ENDIF
             ENDIF
          ENDIF

5.7.2. Adaptive Pacing Example

   The following example illustrates a receiving implementation that adjusts the
   window size and granted units based on buffer availability and transport
   utilization.

   NOTE: This example ignores other factors which might compel the receiving
   implementation to adjust the window size (i.e.  Outbound queue length, traffic
   priority, ...)

   Consider the following variables, in addition to InitialWindowSize,
   CurrentWindow and FCACKOwed:

      GrantDelayed     - Boolean
      GrantedUnits     - Outstanding Units

5.7.2.1. Circuit Startup

          CurrentWindow    = InitialWindowSize
          FCACK            = FALSE
          GrantDelayed     = FALSE
          GrantedUnits     = 0
          Repeat Window Operator

5.7.2.2. Check Buffers Available ( X)

          Can my implementation afford to grant X units just now?

5.7.2.3. Buffers Become Available

A.K. Bartky                                                  [Page 70]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

          IF Check Buffers Available THEN
             CurrentWindow--;
             Send FCIND( Decrement Window)
             GrantDelayed = FALSE
          ELSE
             Wait on buffers to become available (LIFO)
          ENDIF

5.7.2.4. Repeat Window Operator

          IF Check Buffers Available (CurrentWindow) THEN
              Send FCIND( Repeat Window)
          ELSE
             GrantDelayed = TRUE
             Wait on buffers to become available (FIFO)
          ENDIF

5.7.2.5. Increment Window Operator

          IF Check Buffers Available ( CurrentWindow + 1) THEN
              CurrentWindow++
              Send FCIND( Increment Window)
          ELSE
              Repeat Window Operator
          ENDIF

5.7.2.6. Send FCIND( operator)

          FCACKOwed     = TRUE
          GrantedUnits += CurrentWindow
          Encode and Transmit FCIND piggybacked or as IFCIND

5.7.2.7. An FCACK Arrives from Sender

          GrantedUnits--;
          IF NOT FCACKOwed THEN
             Protocol Violation
          ENDIF
          FCACKOwed = FALSE;
          IF NOT GrantDelayed THEN
             IF GrantedUnits < CurrentWindow THEN
                 Increment Window Operator
             ELSE IF GrantedUnits == CurrentWindow THEN
                 Repeat Window Operator
             END
          ENDIF

5.7.2.8. A Non-FCACK Frame Arrives from Sender

A.K. Bartky                                                  [Page 71]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

          GrantedUnits--;
          IF NOT GrantDelayed THEN
             IF FCACKOwed THEN
                IF GrantedUnits < CurrentWindow THEN
                   Protocol Violation
                END
             ELSE
                IF GrantedUnits <= CurrentWindow THEN
                   Repeat Window Operator
                ENDIF
             ENDIF
          ENDIF

5.7.2.9. Example Flows from the Above Implementation

A.K. Bartky                                                  [Page 72]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

   -----SENDER-----                     ----RECEIVER----
   Granted   Window                     Window   Granted
     0         2   circuit established    2         0
     2         2   <-------- FCIND(Rpt)   2         2
     1         2   FCACK-------------->   2         1
     4         3   <-------- FCIND(Inc)   3         4
     3         3   FCACK-------------->   3         3
                          +- FCIND(Rpt)   3         6
     2         3   DATA---|----------->   3         5
     1         3   DATA---|----------->   3         4
     4         3   <------+
     3         3   FCACK-------------->   3         3
     6         3   <-------- FCIND(Rpt)   3         6
     5         3   FCACK-------------->   3         5
     4         3   DATA--------------->   3         4
     3         3   DATA--------------->   3         3
                          +- FCIND(Rpt)   3         6
     2         3   DATA---|----------->   3         5
     1         3   DATA---|----------->   3         4
     0         3   DATA---|----------->   3         3
     3         3   <------+
     2         3   FCACK-------------->   3         2
     6         4   <-------- FCIND(Inc)   4         6
     5         4   FCACK-------------->   4         5
     4         4   DATA--------------->   4         4
                                        Waiting on Buffer
                          +- FCIND(Dec)   3         7
     3         4   DATA---|----------->   3         6
     2         4   DATA---|----------->   3         5
     1         4   DATA---|----------->   3         4
     0         4   DATA---|----------->   3         3
     3         3   <------+
     2         3   FCACK-------------->   3         2
                                        Waiting on Buffer
                          +- FCIND(Dec)   2         4
     1         3   DATA---|----------->   2         3
     0         3   DATA---|----------->   2         2
     2         2   <------+
     1         2   FCACK-------------->   2         1
     4         3   <-------- FCIND(Inc)   3         4
     3         3   FCACK-------------->   3         3
     6         3   <-------- FCIND(Rpt)   3         6
     5         3   FCACK-------------->   3         5
     4         3   DATA--------------->   3         4
     3         3   DATA--------------->   3         3
     6         3   <-------- FCIND(Rpt)   3         6

5.8. Other Considerations

A.K. Bartky                                                  [Page 73]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

5.8.1. Protocol Violations

   The following events shall be considered protocol violations:

   1.  Sender exceeds granted units or does not acknowledge FCIND on first  frame
   after its receipt (the receiver can not discern the difference between the
   two).

   2.  Receiver does not follow a Reset Window Operator with an Increment Window
   Operator.

   3.  Receiver has two unacknowledged FCINDs ( other than Reset Window)
   outstanding.

   4.  Receiver sends Decrement Window Operator with a window size of one.

   Actions taken on protocol violations are not specified in this document and are
   currently implementation specific.

A.K. Bartky                                                  [Page 74]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

Acknowledgments

   Original RFC 1434 Authors:

   Roy C. Dixon, IBM
   David M. Kushi, IBM

   Chair APPN Impementors' Work Shop Data Link Swtiching Related Interest Group

   Louise Herndon Wells, ITI

   Working Group Chairs (and significant contributors to this document)

   Connect/Disconnect (State Machines): Steve Klein, IBM
   Capabilities Exchange: Wayne Clark, Cisco Systems
   Flow Control (Adaptive Pacing): Shannon Nix, Metaplex

   Other significant contributors:

   Gene Cox IBM
   Peter Gayek, IBM
   Paul Brittain, Data Connection Limited

References

     1) ISO 8802-2/IEEE Std 802.2 International Standard,
        Information Processing Systems, Local Area Networks, Part 2:
        Logical Link Control, December 31, 1989

     2) The NETBIOS Frames Protocol, IBM Local Area Technical
        Reference, SC30-3383-03, Chapter 5, December 1990

     3) ISO/IEC DIS 10038 DAM 2, MAC Bridging, Source Routing
        Supplement, December 1991

   Security Considerations

   Security issues are not discussed in this memo.

A.K. Bartky                                                  [Page 75]RFC XXXX      DLSw: Switch-to-Switch Protocol                June 1994

Editor's Address

   Alan K. Bartky
   Manager of Technology
   Sync Research Inc.
   7 Studebaker
   Irvine, CA 91728-2013

   Phone: (714)588-2070
   EMail: [email-masked]

   Note: Any questions or comments relative to the contents of this RFC should be
   sent to the following Internet address:
      [email-masked].

   This address will be used to coordinate the handling of responses.

A.K. Bartky                                                  [Page 76]